Tricks of the Mac Game Programming Gurus/TricksOfTheMacGameProgrammingGurus.iso/Information/CSMP Digest/volume 1/csmp-v1-176.txt

Text File | 1994-12-08 | 50.8 KB | 1,394 lines | [TEXT/R*ch]

C.S.M.P. Digest             Mon, 05 Oct 92       Volume 1 : Issue 176

Today's Topics:

    Stymied++!  VBL Cursor Watching ideas?
    Vertical Text drawing?
    Spreadsheet like view
    Loading Resources into MF Temp Mem.
    updating finder windows
    HOW IS QUICKBASIC FOR THE MAC?
    Ah, but I am clever in how I patch, no?



The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  (This means you can't post questions to the
digest.)

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
cs.uoregon.edu).  Article threads are not added to the digest until the last
article added to the thread is at least one month old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The entire digest is available for anonymous ftp from ftp.cs.uoregon.edu
[128.223.8.8] in the directory /pub/mac/csmp-digest.  Be sure to read the
file /pub/mac/csmp-digest/README before downloading any files.  The most
recent issues are available from sumex-aim.stanford.edu [36.44.0.6] in the
directory /info-mac/digest/csmp.  If you don't have ftp capability, the sumex
archive has a mail server; send a message with the text '$MACarch help' (no
quotes) to [e-mail] for more information.

The digest is also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new issue as it is created.  Sorry, back issues
are not available through the mailing list.

Send administrative mail to [e-mail].


-------------------------------------------------------

From: [e-mail] (Scott Bronson)
Subject: Stymied++!  VBL Cursor Watching ideas?
Date: 21 Jul 92 06:34:45 GMT

(The postincrement represents the minor cookie at the end of this letter.)

I've run into a real snag with my cursor-watching VBL idea (that I posted
to the 'net a few days ago--it may be archived if the article has expired).
Basically, I cannot see a good way to make my code future-compatible without
taking an incredible performance hit.  Here are the ways that I have tried:

The first way I tried was the fastest.  I was getting upwards of 170 iterations
per tick by PPosting() an event, checking the event's modifiers field that got
filled in, then flushing it.  A lot of people frowned on this idea, so I tried
a few other techniques.  Unfortunately, none performed better.

OSEventAvail and EventAvail are out.  I cannot get more than 48 iterations per
tick using OSEventAvail, and EventAvail ended up somewhere around eight iters
per tick.  Totally unacceptable if they are to be VBLs because they'd probably
suck up more cycles than save.

GetKeys runs in great time.  I can get 127 iterations per tick using some
cool key-watching code that I came up with.  Then I decided that I shouldn't
just *assume* that GetKeys can be called from a VBL.  I was astounded that it
can't!  Such a fast, low-level call that may move or purge memory?!?  Rats.

So, I'm stuck.  Here are my options as I see them now:

o Use my super-fast first idea of posting and always flushing the event, hoping
  that because the event is always flushed and because the event gets posted
  and removed by a VBL, the system will not be able to choke on it.
o Use some slow code based on OSEventAvail that I have up and running, but can
  only get 48 iterations per tick (on a IIci).
o Patch some other trap (GNE?) so that I can use my sufficiently fast GetKeys
  code.  Problem is, your traps get disabled when your app gets switched out.
o Use some other solution that I haven't thought of yet (and you're going to
  tell me :-).

I'd like to hear what you guys think would be best.  Right now I think I'll
keep using the first code that I posted, but waking up my application with
WakeUpProcess() rather than leaving the app1 event in the queue.  Am I
overlooking something obvious?  Is it possible and future compatible to
install a patch that will not be removed when my app switches out?

Pipe Dream: Obviously PPostEvent can get at the current state of the
modifiers super-quick and at VBL time.  Is it possible for me to do the
same?

Just doing my part to save precious machine cycles...

    - Scott


- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-

I thought it would be a real shame that my tuned key-watching code would
go unused, so I'm hoping that someone else may find it useful.  If you do
use it, all I ask is that you mail me a short letter telling me how.  I will
support this code if you have any questions.  This code is now public domain.

    short gOldKeys = 0L; // Global var holding current state of modifiers

    Boolean ModifiersChanged( void )
    {
        KeyMap km;
        register Boolean on = false;
        asm {
            PEA    km
            GetKeys
            MOVE.L    km[1],D1
            ANDI.W    #0x800F,D1
            CMP.W    gOldKeys,D1
            BEQ.S    @exit
            MOVE.W    D1,gOldKeys
            MOVEQ    #1,on
        @exit:
        } return on;
    }

+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 23 Jul 92 17:48:20 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <scott.711700485@mcl>, [e-mail] (Scott Bronson) writes:

> I've run into a real snag with my cursor-watching VBL idea...

[different techniques described, with the fastest ones being the least
"future-safe"]

> Pipe Dream: Obviously PPostEvent can get at the current state of the
> modifiers super-quick and at VBL time.  Is it possible for me to do the
> same?

Well, you could bite the bullet and peek at the low-memory area where the
modifier flags are kept (which is obviously what PPostEvent is doing). And
if your code is very successful and you make a lot of money from it, then
you'll have the resources to bring out a new, slower version when it breaks
under a future, faster machine. :-)

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00
PenWindows--the CP/M of pen computing?

---------------------------

From: Steve Kohlmeyer
Subject: Vertical Text drawing?
Date: 22 Jul 92 18:32:54 GMT
Organization: University of Minnesota

Hello Netters,
Does anyone know an easy way to draw text vertically?  I want all of
the letters rotated as well as the whole word -- like the label on a graph.

Thanks for any replies!
Steve Kohlmeyer
[e-mail]



+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Organization: Kalamazoo College
Date: Wed, 22 Jul 1992 20:24:11 GMT

[e-mail] writes:
>Does anyone know an easy way to draw text vertically?  I want all of
>the letters rotated as well as the whole word -- like the label on a graph.

If this isn't on the FAQ, it should be.

You can't do it directly.  Draw them into an offscreen bit/pixmap,
rotate it, and CopyBits it to the screen.  QuickDraw GX, due out next
year, will offer support for drawing rotated text.
- --
 Jamie McCarthy      Internet: [e-mail]      AppleLink: j.mccarthy
 He let the contents of the bottle do the thinking
 Can't shake the devil's hand and say you're only kidding            - TMBG

---------------------------

From: [e-mail] (Greg Trimper)
Subject: Spreadsheet like view
Date: 17 Jul 92 01:36:30 GMT
Organization: Enterprise Data Systems Incorporated, Appleton WI

[e-mail] (Greg Trimper) writes:

>I am using Think C, and want to implement a spreadsheet-style view
>for displaying and editing data.

>The way I look at it, I have two options:
>1) A dialog with lots of editText items, get each item as it is edited

>2) Draw a window with a TERect for EACH item, and handle data after TE is
>done with it - atoi, for example.

>Is there a good and EASY way of doing this?  I really only need a
>20x5 array of items - a little to big for a Dialog, but seems like it will
>be a pain in a window with TextEdit


Oh, and I should mention that I am trying to avoid the LIST manager, unless
someone knows how to make it select multiple items in either row-row
or column-column multiples.


Greg Trimper   [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Andrew Dent)
Organization: DIALix Services, Perth, Western Australia
Date: Sun, 19 Jul 92 01:48:27 GMT

The easiest way would be to use an off-the-shelf product called Matrix
Engine, from DataPak software. (I haven't used this particular product but
I'm very happy with everything else they've written).

Matrix Engine gives you
- - an easier interface
- - virtual memory for large lists
- - gridline drawing
- - simple arithmetic across columns
- - nueric formattingm
- - hooks to change any behaviour
- - comprehensive memory debugger

List price is $395 and they can be contacted on [phone], [phone]
or via CompuSere 76424, 3027   (Internet [e-mail]).

Another approach would be to start using the Think Class Library - there's a
book coming out soon by a guy called Rich Parker which shows how to use TCL
and AppMaker - based on building a spreadsheet!.

Andy Dent (A.D. Software - Mac & VAX programming)
94 Bermuda Dve, BALLAJURA  Western Australia  6066
Phone/Fax: [phone] (local)  [phone] (International)
       Internet: [e-mail]    Compuserve: 100033,3241


+++++++++++++++++++++++++++

From: [e-mail] (Bill Stackhouse)
Date: 20 Jul 92 18:09:15 GMT
Organization: Informix Software, Inc.


There is a product called StoneTable that is a Think C library
that provides all the functions of the list manager plus:

variable size rows/columns
row/column titles
edit cells/titls in place
each cell can be formatted differently (font, size, just, etc)
user interface to allow resizing/move/copy/hide row/columns, scroll
     text in single cell
and more.

StoneTable is $150 from
   StoneTablet Publishing
   P.O Box 12665
   Portland, OR 97212-0665

   CompuServe 70303,2546
   Internet [e-mail]

They have a brochure on the product that can be requested from the
same address.

Just a happy user
Bill Stackhouse
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Roger Allen)
Date: 21 Jul 92 20:56:52 GMT
Organization: Amdahl Corporation, Sunnyvale CA

In article <[e-mail]> [e-mail] (Greg Trimper) writes:
>[e-mail] (Greg Trimper) writes:
>
>>I am using Think C, and want to implement a spreadsheet-style view
>>for displaying and editing data.
>
>>The way I look at it, I have two options:
>>1) A dialog with lots of editText items, get each item as it is edited
>
>>2) Draw a window with a TERect for EACH item, and handle data after TE is
>>done with it - atoi, for example.
>

The TCL for THINK C 5.0 has a spreadsheet class.  This is probably worth
looking into.  It may be a bit of a stretch to put editing into each
cell, but it should work.

>>Is there a good and EASY way of doing this?  I really only need a
>>20x5 array of items - a little to big for a Dialog, but seems like it will
>>be a pain in a window with TextEdit

Don't be afraid to go OO! (object-oriented) :)  Putting an CEditText
item into each cell should handle it without much work by you.

Roger
- --
> Roger Allen                   |                                        <
> Amdahl Computer Development   | What are you looking here for?         <
> [e-mail]           |                                        <

---------------------------

From: [e-mail] (Steven G Johnson)
Subject: Loading Resources into MF Temp Mem.
Date: 14 Jul 92 20:04:03 GMT
Organization: Massachusetts Institute of Technology

Hello.  I have a large picture resource that I am using for my about
box.  It takes a lot of memory, and I would rather not set the
suggested size of my application to be that much larger just in order
to have the about box work.  So, I was wondering:  is there any way to
load a resource into MultiFinder temporary memory rather than into my
application's memory?  It seems like there should be a way to do this,
but I can't figure it out.

Please respond via email as I am not able to read this newsgroup very
often.  I will post a summary of responses is there is interest (and
if I get any responses).  Thanks in advance for any help.

                    Cordially,
                    Steven G. Johnson


- -----------------------------------------------------------------------------
I really don't understand all this business about signatures.  Mind
your own business!  (Or, if you are really nosy, you can finger me.)
- -----------------------------------------------------------------------------

+++++++++++++++++++++++++++

From: [e-mail] (Steven G Johnson)
Organization: Massachusetts Institute of Technology
Date: Wed, 15 Jul 1992 17:31:35 GMT

Hello again.  I've recieved a number of responses to my request for
information on reading resources into MF temporary memory, as well
as some requests for a summary of responses.

The consensus seems to be that there is no safe way to do this under
System 6, but under System 7 you can use the ReadPartialResource
routine to do the job (after checking the appropriate Gestalt selector
first, of course).

A number of people suggested reading the raw resource fork or putting
the picture into the application's data fork instead, and then perhaps
even modifying the QD capture procs to read it in a little bit at a
times, thus obviating the necessity of having it all in memory at
once.

A couple people suggested setting the zone to be in MF temp. memory,
but as this is undocumented I did not think it was particularly safe
to try (yes, I am weak of heart, I know).

Many thanks for all your help.  Ciao!

                        Cordially,
                        Steven G. Johnson


+++++++++++++++++++++++++++

From: [e-mail] (Jeremy Roussak)
Date: 16 Jul 92 19:57:28 GMT
Organization: Computer Science Dept, QMW, University of London

In <[e-mail]> [e-mail] (Steven G Johnson) writes:

>Hello again.  I've recieved a number of responses to my request for
>information on reading resources into MF temporary memory, as well
>as some requests for a summary of responses.

>The consensus seems to be that there is no safe way to do this under
>System 6, but under System 7 you can use the ReadPartialResource
>routine to do the job (after checking the appropriate Gestalt selector
>first, of course).

This seems awfully complicated.

>A couple people suggested setting the zone to be in MF temp. memory,
>but as this is undocumented I did not think it was particularly safe
>to try (yes, I am weak of heart, I know).

Well, I was one of those people. I don't think there's anything
undocumented about the approach I suggested, which was:

1. Allocate enough memory using MF temporary memory. Cop out
if you can't.

2. Make sure the memory can't move, then call _InitZone to make
it a heap.

3. Save the current zone (_GetZone), the _SetZone to your new
heap.

4. Load and use the resource(s)

5. Release the resources, _SetZone to the old zone and dispose
of the MF memory.

As I mentioned, I haven't tried this, but I have been giving it
some thought recently. I can't think of any objections to this
method, which will work under any system if MF is running.

Would someone better versed than I in the internals of the
Memory Manager like to comment?

Jeremy
>Many thanks for all your help.  Ciao!

>                                               Cordially,
>                                               Steven G. Johnson

+++++++++++++++++++++++++++

From: [e-mail] (Larry Rosenstein)
Date: 17 Jul 92 00:51:16 GMT
Organization: Taligent, Inc.

In article <[e-mail]>, [e-mail]
(Jeremy Roussak) wrote:
>
> Well, I was one of those people. I don't think there's anything
> undocumented about the approach I suggested, which was:

That should work (as long as the resource isn't marked System, of course),
although you have to know how much extra to allocate for the heap zone.

You would still need to handle the case where there isn't enough temporary
memory available and fall back on a simpler picture, or read the picture
directly from disk.

Larry Rosenstein
Taligent, Inc.

[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Mike Dodd)
Date: Fri, 17 Jul 1992 04:41:52 GMT
Organization: Apple Computer Inc.

In article <[e-mail]>, [e-mail] (Jeremy Roussak) writes:
> Well, I was one of those people. I don't think there's anything
> undocumented about the approach I suggested, which was:
>
> 1. Allocate enough memory using MF temporary memory. Cop out
> if you can't.
>
> 2. Make sure the memory can't move, then call _InitZone to make
> it a heap.
>
> 3. Save the current zone (_GetZone), the _SetZone to your new
> heap.
>
> 4. Load and use the resource(s)
>
> 5. Release the resources, _SetZone to the old zone and dispose
> of the MF memory.

i don't know what the original intent of loading resources into the
multifinder zone was, but this seems an expensive (time-wise) method.
i think that setting up and shutting down zones like this is relatively
time consuming...

- -Mike Dodd-
Apple Computer
** What I say is my opinion. Not Apple's. **


+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 17 Jul 92 18:53:52 GMT
Organization: Taligent

In article <[e-mail]>, [e-mail] (Mike Dodd)
writes:
>
> i don't know what the original intent of loading resources into the
> multifinder zone was, but this seems an expensive (time-wise) method.
> i think that setting up and shutting down zones like this is relatively
> time consuming...

The original poster didn't have room in his application heap for a picture he
wanted to render for his About Box.

Creating your own zone isn't much different (time-wise) that getting the handle
for it in the first place, and is certainly _much_ less expensive than either
the eventual reading of the picture from the disk or the drawing of it to a
window.

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.

+++++++++++++++++++++++++++

From: [e-mail] (Jeremy Roussak)
Date: 18 Jul 92 20:12:23 GMT
Organization: Computer Science Dept, QMW, University of London

In article <[e-mail]>, [e-mail] (Mike Dodd)
writes:
>
> i don't know what the original intent of loading resources into the
> multifinder zone was, but this seems an expensive (time-wise) method.
> i think that setting up and shutting down zones like this is relatively
> time consuming...

I forget what the original poster wanted to do (something
connected with a large PICT and not wanting to keep all the
necessary memory for himself all the time). My reasons for
giving it thought were connected with an INIT (extension) I'm
writing. To configure this INIT, a large code resource is
loaded and run. Since the INIT is running at the time in the
partition of the current app, it doesn't know how much free
memory may be available. I ran into some problems with DarkSide
in particular, since it (laudably) has almost no memory free in
its partition. Similarly, the system heap may well not have
much memory free.

At the moment, I just put up an alert suggesting switching to
another app, but it would be much better if I could load my
resource into temporary memory, if it's available.

Jeremy

+++++++++++++++++++++++++++

From: [e-mail] (Scott Bronson)
Date: 21 Jul 92 21:57:27 GMT

If I recall, the original reson for pulling this huge resource into a small
application heap was to draw a color about box with a PICT.  If so, IM-V
describes around page 90 or so how to spool a picture in from the disk.
I was hoping someone who knows more about this than I would mention this,
as the one time I tried to get this code to work I couldn't get it to stop
crashing.  I'm fairly certain that it was my fault, but as such, I don't
feel like an expert with PICT spooling.

You could probably rewrite GetPICTData to pull the opcodes in using partial
resource calls, but, personally, I would just stick the PICT data into the
application's data fork and spool from that using (almost?) the exact code
from the book.  Very compatible, suitably fast, and it's all in IM-V page 88.

    - Scott

+++++++++++++++++++++++++++

From: [e-mail] (Paul Frederick Snively)
Date: Wed, 22 Jul 92 22:13:40 PDT
Organization: The Portal System (TM)

I have an alternative, hopefully simpler, suggestion:

Use Gestalt to determine whether temporary memory is `real memory' or not.
If it is, then allocate a small (say, zero byte) temporary handle, and call
HandleZone on it to get the temorary zone.  Then you can GetZone the current
Zone, SetZone to the temporary zone, manage memory, and when you're done,
SetZone back to the old Zone.

Incidentally, when using temporary memory, it's best to _avoid_ MoveHHi,
because MultiFinder/The Process Manager allocate application space _from the
top down_, so MoveHHi on temporary handles will actually tend to _cause_ heap
fragmentation rather than alleviate it.  Instead, you may wish to consider
using ReservMem to attempt to reserve memory, and then allocate your temporary
handle.  ReservMem attempts to reserve memory as _low_ in the heap as possible
(it's what NewPtr calls to do its thing).

Paul Snively
Dissolute Wandering Hacker
[e-mail]

---------------------------

From: [e-mail]
Subject: updating finder windows
Date: 19 Jul 92 08:55:17 GMT
Organization: Oxford University VAXcluster

I am writing a drag-and-drop application which will swap the case of the
names of files dropped on it (because I can't get AFE to give me lower
case names for files on a PC disk).  My problem is that I can't get the
finder to update the name change immediately (althogh closing the folder
and reopening it shows that the names have in fact been changed).  I sent
this query to info-mac and got a unanimous answer - I have to change the
modification data of the folder containing the files.  I believe I have
done this with the following code:

            fileName = (char *) fss->name;
            SwapName(swappedName, fileName);
            err = FSpRename(fss, swappedName);
            /* touch the home directory to update finder windows */
            vParams.dirInfo.ioCompletion = nil;
            vParams.dirInfo.ioVRefNum = fss->vRefNum;
            vParams.dirInfo.ioFDirIndex = -1;
            vParams.dirInfo.ioDrDirID = fss->parID;
            vParams.dirInfo.ioNamePtr = temp;
            err = PBGetCatInfo(&vParams, FALSE);
            *vParams.dirInfo.ioNamePtr = 0;
            GetDateTime(&vParams.dirInfo.ioDrMdDat);
            err = PBSetCatInfo(&vParams, FALSE);
            err = PBFlushVol(&vParams, FALSE);

This code does change the modification date of the folder (as shown by
doing a get info on the folder) but does not update the finder window
containing the files.  What am I missing???

  Thanks for all help
      Andrew Rohl

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Organization: Kalamazoo College
Date: Mon, 20 Jul 1992 17:48:56 GMT

[e-mail] writes:
>My problem is that I can't get the
>finder to update the name change immediately (althogh closing the folder
>and reopening it shows that the names have in fact been changed).  ...
>I have to change the
>modification data of the folder containing the files.  I believe I have
>done this with the following code:
>
>[code deleted]
>
>This code does change the modification date of the folder (as shown by
>doing a get info on the folder) but does not update the finder window
>containing the files.  What am I missing???

I think you want to update the date of the file's directory's parent,
rather than the directory itself.  I'm not too bright when it comes
to the File Manager, so I could be wrong;  still, it looks like no one
else is going to answer this question.  Anyway, here's the code I use
(I stole it):


    /* Straight from Jon Waette's personal library.  I made a few
     * minor changes.
     */
void touchDir(short vol, long dir)
{
    CInfoPBRec info;
    Str63 name;

    clearMemory(&info, sizeof(info)); // Play it safe

    info.dirInfo.ioDrDirID = dir;
    info.dirInfo.ioVRefNum = vol;
    info.dirInfo.ioNamePtr = name;
    info.dirInfo.ioFDirIndex = -1;

    FailOSErr(PBGetCatInfo(&info, FALSE)); // Get the info on the folder

    info.dirInfo.ioCompletion = 0;
    info.dirInfo.ioDrDirID = info.dirInfo.ioDrParID;
    info.dirInfo.ioFDirIndex = 0;
    GetDateTime(&info.dirInfo.ioDrMdDat);

    FailOSErr(PBSetCatInfo(&info, FALSE)); // Set the modified time
}
- --
 Jamie McCarthy      Internet: [e-mail]      AppleLink: j.mccarthy
 I suppose ya don't think I was run over by a streetcar!

+++++++++++++++++++++++++++

From: [e-mail] (Tommy Brown)
Organization: FidoNet node 1:2603/204 - Not Even Odd, Forest Hills NY
Date: Mon, 20 Jul 1992 22:05:00 GMT

I don't think that you CAN get the Finder to update the window immediately,

because as far as I know, the Finder just doesn't constantly poll the disk to
see if anything's been changed. The only thing I can think of is if you were

somehow able to get a WindowPtr to the window that the file's in. Then you

could call InvalRect, either over the whole window or just the rectangle of

the icon which you want to change, which I believe you can get by calling

GetFInfo. How to get a WindowPtr to the correct window, though, I don't know.

- --
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
 Tommy Brown - Internet: [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Elizabeth Wylie)
Date: 22 Jul 1992 20:33:23 GMT
Organization: U. C. Berkeley Open Computing Facility

In article <[e-mail]> [e-mail] (Tommy Brown) writes:
>I don't think that you CAN get the Finder to update the window immediately,
>
>because as far as I know, the Finder just doesn't constantly poll the disk to
>see if anything's been changed. The only thing I can think of is if you were
>

You'd be surprised what the finder does.  Put a trap break on HFSDispatch sometime.  You'll be surprised.  The finder is constantly cycling through open windows and getting folder dates etc.

If you want to force the window to update, change the modification date of the folder containing the item you changed.

The finder always updates for me.  Sometime soon I may be posting a small INIT that does this as well as patch a few traps.  The INIT automatically relocates items dropped in a folder.

Just to a PBGetCatInfo followed by a PBSetCatInfo.  But remember that the ioDirID field (and a few others, I think) get chewed after the call is complete.

- -E Wylie

and


---------------------------

From: [e-mail]
Subject: HOW IS QUICKBASIC FOR THE MAC?
Date: 20 Jul 92 23:08:39 GMT
Organization: Computing Services, UC Davis

I have a compiled PC program I wrote in QuickBasic.  I want to get one done for
the Mac.  Questions:
1) How is QuickBasic for the Mac? Please only answer this one if you know what
   you are talking about.
2) What applications generators do you recommend? (Anyone can answer this.)

The program is not database oriented.  It is a questionnaire whose answers are

+++++++++++++++++++++++++++

From: [e-mail]
Date: 21 Jul 92 04:08:22 GMT
Organization: University of California, Berkeley

I don't know if you deem me worthy to respond, but I
programmed in QuickBasic on the mac for about 4
years.  For simple stuff, it's VERY easy to use;
development time is almost zero.  For math-intensive
stuff (convolutions, etc.), Think C compiled code
runs some 5 times faster that QuickBasic compiled
code.  Also, it is my understanding (from Microsoft
support) that Microsoft has basically abandoned the
product.  Hope this helps.
- --
- ------------------------------------------------------------------
Larry Cormack         *  When exploring the unknown, by definition
Physiological Optics  *  you do not know what you will find.
U. C. Berkeley        *        *     *     *     *     *     *     *

+++++++++++++++++++++++++++

From: [e-mail] (Mark Hayes)
Date: 21 Jul 92 05:04:37 GMT
Organization: Boston University, Boston, MA, USA

In article <[e-mail]> [e-mail] writes:
>  Also, it is my understanding (from Microsoft
>support) that Microsoft has basically abandoned the
>product.  Hope this helps.

For what this is worth, I just received an updated version of
QuickBasic from Microsoft as a result of having requested that I
be put on an upgrade-requestors list over a year ago. The new
version is supposedly System 7 compatible, though it doesn't
let you do anything particularly "System 7 lustful".



+++++++++++++++++++++++++++

From: [e-mail] (fred baker)
Date: 21 Jul 92 05:29:58 GMT
Organization: Nyx, Public Access Unix at U. of Denver Math/CS dept.

In article <[e-mail]> [e-mail] writes:
>I have a compiled PC program I wrote in QuickBasic.  I want to get one done for
>the Mac.  Questions:
>1) How is QuickBasic for the Mac? Please only answer this one if you know what
>   you are talking about.
>2) What applications generators do you recommend? (Anyone can answer this.)
>
>The program is not database oriented.  It is a questionnaire whose answers are

Run, do not walk away from MS QuickBASIC.  The last time it was updated was in
1988.  It is not 32-bit compatible, does not produce 32-bit compatible
software, supports nothing more than the old eight-color QuickDraw model, and
what is more, *still* costs as much as it did in 1988.  How's that for a
run-on sentence?

Unfortunately, you're not going to do much better elsewhere.  The last I've
heard, Zedcor still hasn't updated its ZBasic product (although it was leaps
and bounds better than MS QuickBASIC), and as for True Basic, my only
experience was with the demo, and it wouldn't run under System 7.  Oh yeah;
MS QuickBASIC doesn't work too well with System 7 either.

Would you like to buy my copy, *real* cheap? :)

Fred

+++++++++++++++++++++++++++

From: [e-mail] (Ralph Gonzalez)
Date: 22 Jul 92 19:05:42 GMT
Organization: Rutgers Univ., New Brunswick, N.J.

[e-mail] (Mark Hayes) writes:

>For what this is worth, I just received an updated version of
>QuickBasic from Microsoft as a result of having requested that I
>be put on an upgrade-requestors list over a year ago. The new
>version is supposedly System 7 compatible, though it doesn't
>let you do anything particularly "System 7 lustful".

I got my name on this list, too, but despite periodical calls to
Microsoft I haven't gotten any upgrade info.

To the original poster, note that Mac QuickBASIC lacks a few of the
PC versions features, such as data structures(!) -- I wonder if the
update has this?  On the other hand, it offers an easy approach to
writing Mac programs without using the Toolbox directly (though you'll
have to do some tricky and frustrating programming to get all the
details of the Mac interface working properly).  To just port a PC
program should be pretty easy, though.

- -Ralph
- --
Ralph Gonzalez, Computer Science, Rutgers Univ., Camden, NJ
Phone: [phone]; Internet: [e-mail]
- --

+++++++++++++++++++++++++++

From: [e-mail] (Matt Mora)
Date: 22 Jul 92 18:46:13 GMT
Organization: SRI International, Menlo Park, California

In article <[e-mail]> [e-mail] (Mark Hayes) writes:
>In article <[e-mail]> [e-mail] writes:


>For what this is worth, I just received an updated version of
>QuickBasic from Microsoft as a result of having requested that I
>be put on an upgrade-requestors list over a year ago. The new
>version is supposedly System 7 compatible, though it doesn't
>let you do anything particularly "System 7 lustful".

I just received my copy today. It cost $10.00 to upgrade.
I hear that it fixes a few bugs but causes one new one.
I have released some pure code resources that lets quickbasic
do some cool stuff. Look for it at the archive sites.



Matt





- --
___________________________________________________________
Matthew Mora                |   my Mac  [e-mail]
SRI International           |  my unix  [e-mail]
___________________________________________________________

+++++++++++++++++++++++++++

From: [e-mail] (Matt Mora)
Date: 22 Jul 92 18:50:56 GMT
Organization: SRI International, Menlo Park, California

In article <[e-mail]> [e-mail] writes:

>1) How is QuickBasic for the Mac? Please only answer this one if you know what

It basically dead right now. Though microsoft has releaseda version of it
that works with system seven finally.




Matt
- --
___________________________________________________________
Matthew Mora                |   my Mac  [e-mail]
SRI International           |  my unix  [e-mail]
___________________________________________________________

---------------------------

From: [e-mail] (Kent Borg)
Subject: Ah, but I am clever in how I patch, no?
Organization: Camex Inc., Boston MA
Date: Mon, 13 Jul 1992 23:26:32 EDT


So MacDTS says I am right to worry that I am possibly doing Bad Stuff,
but they didn't say why.  They drive me to ask the folks who know.
You.

I am patching _GetResource in a "double-dip" technique.  I watch for a
magic combination of resource ID and type.  When I spot it I call the
address I originally found for _GetResource, tamper with the results
in the form of appending some clever stuff to the end of the resource,
but then leave it in the heap and resource map (but, I hope, in such a
way as to not have it get written back out in my tampered state), and
finally jump to the original _GetResource address to let it find my
version of the PREC 103 (yes, I admit it, I am playing with printing
stuff).

The queston: Will my jumping to the original address keep any
come-from patches happy (and under system 7 maybe this is no problem)?
Does it absolve me the sins of having called the original address?

Thanks.


P.S.  Please post any responses, BUT if you have something really
useful to say, please cc: me by mail.  Our news feed seems to be
nearly two weeks late on the inbound and I would like to get any
clever answers sooner than that.  (If you want to send mail to
"[e-mail]" and tell the System Administration types that this is
important enough to fix, I wouldn't complain...)

- --
Kent Borg                                   [e-mail] or [e-mail]
                                            H:[phone]  W:[phone]
As always, things look better when some costs are left out.
                              -Economist 3-28-92 p. 94

+++++++++++++++++++++++++++

From: [e-mail] (Michael Hecht)
Date: 14 Jul 92 14:47:31 GMT
Organization: SAS Institute Inc.

In article <[e-mail]>, [e-mail]
(Kent Borg) describes a "double-dip" technique for legally tail-patching
GetResource.

A perhaps legal tail-patching method that I thought up once was this:

patch_code:
   unpatch myself from _GetResource
   call _GetResource with my arguments
   repatch myself into _GetResource

   play around with the results
   return

patch_installer:
   patch patch_code into _GetResource

It would seem that this would satisfy the requirements of any come-from
patch to _GetResource, since it would appear to them that they come from
the invocation within my patch code.

Comments?

- --Michael

=======================================================================
Michael P. Hecht                 | Internet:  [e-mail]
SAS Institute Inc.; Cary, NC USA | AppleLink: SAS.HECHT

+++++++++++++++++++++++++++

From: [e-mail] (Charlie Reiman)
Date: 14 Jul 92 17:56:11 GMT
Organization: Apple Computer Inc., Cupertino, CA

[e-mail] (Michael Hecht) writes:

>In article <[e-mail]>, [e-mail]
>(Kent Borg) describes a "double-dip" technique for legally tail-patching
>GetResource.

>A perhaps legal tail-patching method that I thought up once was this:

>patch_code:
>   unpatch myself from _GetResource
>   call _GetResource with my arguments
>   repatch myself into _GetResource

>   play around with the results
>   return

>patch_installer:
>   patch patch_code into _GetResource

I'm not commenting on the wisdom of such a ploy to avoid tail patches,
however, I would strongly suggest you make your code "re-entrant proof",
rather than skanking around with _get/_setTrapAddress.

Your patch probably has some static storage in memory. Make one word of
it an "inUse" flag. When you enter your patch, check the flag. If it is
set, simply call the original trap. If it is clear, set it and proceed
to do your evil mucking around. When your are finished mucking around,
clear the flag and exit as you normally would (by jumping to the
original code).

So what does this buy you? Simple: You can invoke the patch you are
trapping from within your patch without needing to change the trap
address.

I use this technique in a large, very skanky hack to prevent my patches
from colliding with my interrupt routines when the are saving and
restoring A5.

FYI: Tail patches are a bad thing. I suggest checking out the
TechNotes.
- --
Charlie Reiman - Speaking as an individual, not for Apple Computer.
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 14 Jul 92 18:10:30 GMT
Organization: Taligent

In article <[e-mail]>,
[e-mail] (Michael Hecht) writes:
>
> A perhaps legal tail-patching method that I thought up once was this:
>
> patch_code:
>    unpatch myself from _GetResource
>    call _GetResource with my arguments
>    repatch myself into _GetResource
>
>    play around with the results
>    return
>
> patch_installer:
>    patch patch_code into _GetResource
>
> It would seem that this would satisfy the requirements of any come-from
> patch to _GetResource, since it would appear to them that they come from
> the invocation within my patch code.

Your method doesn't solve the problem of tail-patching.

Come from patches determine when they should kick in by looking at the return
address on the stack. Either way you do it (jumping directly to the saved
original address or putting the original address back into the trap table), the
return address is still going to point back to your patch.

By the way, removing your patch from the trap table is tricky business. You have
to take into account the possibility that someone has applied a patch over
yours. If that has occured, there is no way for you to remove your patch (at
least, not without affecting the uber-patch).

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.


+++++++++++++++++++++++++++

From: [e-mail] (Scott Lindsey)
Date: 14 Jul 92 22:18:14 GMT
Organization: Claris Corporation, Vancouver WA

In article <[e-mail]>, [e-mail] (Michael Hecht) writes:
>
> In article <[e-mail]>, [e-mail]
> (Kent Borg) describes a "double-dip" technique for legally tail-patching
> GetResource.
>
> A perhaps legal tail-patching method that I thought up once was this:
>
> patch_code:
>    unpatch myself from _GetResource
>    call _GetResource with my arguments
>    repatch myself into _GetResource
>
>    play around with the results
>    return
>
> patch_installer:
>    patch patch_code into _GetResource
>
> It would seem that this would satisfy the requirements of any come-from
> patch to _GetResource, since it would appear to them that they come from
> the invocation within my patch code.
      ^^^^^^^^^^ ^^^^^^ ^^ ^^^^^ ^^^^
.. and not from the original caller, which is what Apple's tail-patch-
sensitive code would be looking for.  The whole problem of tail patches is the
return address that's on the stack.  In some of Apple's patches, they
check this for (in general) certain ROM addresses.  If it's your address on
the stack instead, Apple's patch won't work.


- --
Scott Lindsey <[e-mail]>

+++++++++++++++++++++++++++

From: [e-mail] (Pete Gontier)
Date: Wed, 15 Jul 92 07:58:34 GMT
Organization: cellular

[e-mail] (Kent Borg) writes:


>So MacDTS says I am right to worry that I am possibly doing Bad Stuff,
>but they didn't say why.  They drive me to ask the folks who know.
>You.

DTS just says these things on general principle. If you mess with the
fundamental operation of the machine, which is what you're doing when
you do a hack against the trap mechanism, which is essentially what
you're doing, it may or may not preclude Apple from doing some other
hack, which may or may not include the same sort of thing as your hack.

>I am patching _GetResource in a "double-dip" technique.  I watch for a
>magic combination of resource ID and type.  When I spot it I call the
>address I originally found for _GetResource, tamper with the results
>in the form of appending some clever stuff to the end of the resource,
>but then leave it in the heap and resource map (but, I hope, in such a
>way as to not have it get written back out in my tampered state), and
>finally jump to the original _GetResource address to let it find my
>version of the PREC 103 (yes, I admit it, I am playing with printing
>stuff).

Steve Brecher revealed in a developer's panel talk at a recent MacWorld
that this is one of the tricky things Suitcase does. You are free to
interpret this info as you will. :-)

>The queston: Will my jumping to the original address keep any
>come-from patches happy (and under system 7 maybe this is no problem)?
>Does it absolve me the sins of having called the original address?

Your jumping absolves you. The only thing you have to worry about is
what address is on the top of the stack. That's the return address
that got pushed there when _GetResource set off the A-trap mechanism,
and that's what a come-from patch is all about. In this case, if it
ran and returned control to the caller of _GetResource, that would
make *me personally* pretty confident that I had done it right.
- --
 Pete Gontier // EC Technology // [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Peter Creath)
Date: 15 Jul 92 03:09:03 GMT
Organization: Cube Technologies


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Charlie Reiman) writes:
> [e-mail] (Michael Hecht) writes:
>
> >In article <[e-mail]>, [e-mail]
> >(Kent Borg) describes a "double-dip" technique for legally tail-patching
> >GetResource.
>
> >A perhaps legal tail-patching method that I thought up once was this:
>
> >patch_code:
> >   unpatch myself from _GetResource
> >   call _GetResource with my arguments
> >   repatch myself into _GetResource
>
> >   play around with the results
> >   return
>
> >patch_installer:
> >   patch patch_code into _GetResource

No no no.  Well, maybe.  If this is only for your app, in which case
you shouldn't even be patching.  So no.  What you do instead is:

At startup, your INIT takes the trap address (GetTrapAddress) and
stores it somewhere in your snippet of code to be installed as the
patch.  Patch the trap to your new snippet of code.  Your snippet
of code JSR's the address your INIT picked out for you.  Sounds complex,
but it's not too difficult.  Pre-patching and tail-patching aren't
too bad, just make sure you save off and restore all the registers
you use, just in case...

- ----------------------------------------------------------------------------
Peter Creath                 "When I was a boy I was told that anybody could
[e-mail]           become president; I'm beginning to believe it."
                                                           -- Clarence Darrow

+++++++++++++++++++++++++++

From: [e-mail] (Dave Platt)
Date: 17 Jul 92 17:59:23 GMT
Organization: New Technologies Group, Inc.  Palo Alto CA

In article <[e-mail]> [e-mail] writes:

>At startup, your INIT takes the trap address (GetTrapAddress) and
>stores it somewhere in your snippet of code to be installed as the
>patch.  Patch the trap to your new snippet of code.  Your snippet
>of code JSR's the address your INIT picked out for you.  Sounds complex,
>but it's not too difficult.  Pre-patching and tail-patching aren't
>too bad, just make sure you save off and restore all the registers
>you use, just in case...

AAAAAAAaaaaaaaaaaaaagggggggggggggggghhhhhhhhhhhhh.

Pardon.  Hit a nerve there.  Calm down, Dave.  Don't shout so mucj.

Apple has recommended, for YEARS, that programmers avoid tail patching
like the plague.  Don't do it.  Ever.  Period.  If you must patch a
trap, use a head-patch only - exit by JMP'ing to the original trap
handler.

If you tail-patch a trap, then the trap code can't tell where it was
originally called from.  This is a Bad Situation.

The reason:  some of Apple's own bug-fix patches work by installing a
head patch into a trap.  The patch checks the return-address to see
whether it matches a specific address in the ROM;  if so, the patch does
something special (usually to fix a bug which exists in the code which
called the trap, NOT in the trap itself).

It's a odd technique, but there's a good reason for it - it permits
Apple to install a small head-patch to a trap, rather than having to
patch out the entire guts of what may be a fairly large routine or
manager in the ROM.  Much less RAM is used this way.

If you install a tail-patch on a trap, and if it turns out to be a patch
that Apple has used in this way, YOUR TAIL PATCH WILL DISABLE APPLE'S
BUG FIX.  Your INIT-installed patch may cause old bugs to reappear, or
cause crashes or other unexpected behavior, under some System versions,
on some hardware configurations, but perhaps not on others.

This can happen even if your patch is, itself, completely perfect and
blameless (except for the fact that it's a tail patch).

Please DO NOT USE TAIL PATCHES.  They are a useful, obvious technique,
which has been declared off-limits.  It's a shame, but that's how it
goes.

Sorry, I'm shouting again... I'll go have a cola and cool down a bit.

- --
Dave Platt                                                VOICE: [phone]
              Domain: [e-mail]      UUCP: ...netcomsv!ntg!dplatt
 USNAIL: New Technologies Group Inc. 2468 Embarcardero Way, Palo Alto CA 94303

+++++++++++++++++++++++++++

From: [e-mail] (Scott Bronson)
Date: 20 Jul 92 05:45:39 GMT

In <[e-mail]> [e-mail] (Dave Platt) writes:

>In article <[e-mail]> [e-mail] writes:


>Apple has recommended, for YEARS, that programmers avoid tail patching
>like the plague.  Don't do it.  Ever.  Period.  If you must patch a
>trap, use a head-patch only - exit by JMP'ing to the original trap
>handler.

You can chill if you're running System 7.  It uses a cool patching
technique where your patches are kept apart from the system's, so
tail patching is perfectly kosher.  Just be prepared to have your
patch ignored by the system--it'll simply forget about your patch
if it wants to.  (this is oversimplified and please get better info
on this before relying on this.)

    - Scott

+++++++++++++++++++++++++++

From: Quinn <[e-mail]>
Organization: The University of Western Australia
Date: Tue, 21 Jul 1992 02:21:05 GMT

Scott Bronson talks about System 7's new trap patching mechanism...

>(this is oversimplified and please get better info
>on this before relying on this.)

Oh and where would you suggest we get this better info?  I've read
everything I can lay my hands on about System 7 (all the way back
to the Alpha release notes) and the first I heard about the new
patch mechanism was here in c.s.m.p.  But perhaps I missed something.

[Switch to Yorkshire accent]

Ya know when ay was a laad wee had IM I-III and eet told us all sorts
ov uuseful informaytion about the internals of the Mac but we 'ad ta
werk out tha deetails arselves.  Now da younguns 'ave IM VI and eet
gives 'em lots of pretty ecsamples but they donn't get any off da
goodies.

[Switch back to sanity]

Quinn "The Eskimo!"   <[e-mail]>  "Real Coke, Diet .sig"
Department of Computer Science, The University of Western Australia
  -- Bewildered!  Confused!  Situation normal!

+++++++++++++++++++++++++++

From: [e-mail] (Pete Gontier)
Date: Thu, 23 Jul 92 07:18:49 GMT
Organization: cellular

[e-mail] (Quinn) writes:
> I've read
> everything I can lay my hands on about System 7 (all the way back
> to the Alpha release notes) and the first I heard about the new
> patch mechanism was here in c.s.m.p.  But perhaps I missed something.

Now if I could only explain the utility of UseNet to my boss in terms
as simple as these, our company would probably have a full time
internet connection within a week! Unfortunately, bossy doesn't know
anything about patching.

More to the point, if you're worried about the legitimacy of this
information, I've heard it from at least two core members of the System 7
team (Blue Meanies), Dean Yu and Greg Marriott. Dean's on the net all
the time, and Greg is sometimes here, as well, although I am familiar
with him mostly through America Online.

Anyway, Dean actually can narrow it down to one trap you shouldn't tail
patch because you'll screw up a come-from patch Apple couldn't remove in
the newly-standard way. I'm not sure, but if I were up against a wall
on the wrong side of a firing squad, I'd probably guess it's FrontWindow.
- --
 Pete Gontier // EC Technology // [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 23 Jul 92 18:55:29 GMT
Organization: Taligent

In article <[e-mail]>, [e-mail] (Pete Gontier) writes:
>
> Anyway, Dean actually can narrow it down to one trap you shouldn't tail
> patch because you'll screw up a come-from patch Apple couldn't remove in
> the newly-standard way. I'm not sure, but if I were up against a wall
> on the wrong side of a firing squad, I'd probably guess it's FrontWindow.

You know, I thought this was the case, too, based on my memory of something Dean
posted once. However, I recently looked into FrontWindow to see what the deal
was, and didn't see anything out of the ordinary. The only thing I saw was that
FrontWindow was one of those totally replaced traps. In other words, it gets
patched out after INIT time and doesn't chain to the original trap. So it seems
to me that FrontWindow isn't any more special than any of those trap patches
that totally replace the system trap after INIT time.

Looks like it's doing some layer manager sifting before returning the front
window, but that's just a guess.

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.

---------------------------

End of C.S.M.P. Digest
**********************